1. Field of the Invention
The present invention relates to a method and system for converged IP messaging service, and in particular, to a method and system for managing message threads in converged IP messaging service.
2. Description of the Related Art
Many different messaging services, such as Short Message Service (SMS), Multimedia Messaging Service (MMS), email, Instant Messaging (IM) service, etc., exist today. Although these services rely on different technologies, user experiences the services provide partially overlap with each other. For example, it is possible to send text messages using all the services cited above, and all services above except for SMS can support the transfer of multimedia content.
Recently, there has been an emergence of a new type of converged messaging service in which the above-mentioned messaging services are synthetically converged. As used herein, such a converged messaging service is called a “Converged IP Messaging (CPM) service.” The CPM service is an Session Initiation Protocol (SIP)-based service and is required to be capable of freely performing message communication with users of existing messaging services as well as users of the CPM service. Therefore, the CPM service needs to be capable of inter-working with the existing SMS service, IM service, MMS, Push to talk over Cellular (PoC) service, etc. Further, inter-working between a messaging service through established sessions and a messaging service without establishment of sessions should be possible, and thus standardization of such inter-working is now being in progress.
Usually, message transmission/reception in a CPM system is performed according to a process as shown in FIG. 1, and message transmission/reception in an SMS system is performed according to a process as shown in FIG. 2. In order to help understanding of the message transmission/reception process in each system, FIGS. 1 and 2 are based on an assumption that each system includes two users, although each system allows message transmission/reception between multiple users. It is also assumed here that users do not explicitly establish a session before exchanging the messages, i.e. the user who wants to start a conversation can send a message immediately without first requesting the creation of a session.
The CPM service is based on an SIP that provides a protocol to initiate, modify and terminate a session between users. To send messages without initiating a session first, the CPM relies on the SIP MESSAGE extension. FIG. 1 illustrates a typical flow of a message sent from a first user and a second user, represented by a first CPM client 1 and a second CPM client 3 respectively, via a CPM server 2.
In step 101, the first CPM client 1 sends a typical SIP MESSAGE having a configuration as shown in Table 1 to the CPM Server 2.
TABLE 1MESSAGE sip:user2@domain.com SIP/2.0Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkseMax-Forwards: 70From: sip:user1@domain.com;tag=49583To: sip:user2@domain.comCall-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Type: text/plainContent-Length: 18Hello Mark, are you there?
In step 103, the CPM server 2 receives the SIP MESSAGE, identifies if the second CPM client 3 is registered in the CPM server 2, and forwards the SIP MESSAGE having a configuration as shown in Table 2 to the second client 3.
TABLE 2MESSAGE sip:user2@domain.com SIP/2.0Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghdsVia: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4Max-Forwards: 69From: sip:user1@domain.com;tag=49394To: sip:user2@domain.comCall-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Type: text/plainContent-Length: 18Hello Mark, are you there?
The second CPM client 3 receives the message in step 103, and sends back a “200 OK” message having a configuration as shown in Table 3 to the CPM server 2 in step 105.
TABLE 3SIP/2.0 200 OKVia: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;received=192.0.2.1Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;received=1.2.3.4From: sip:user1@domain.com;tag=49394To: sip:user2@domain.com;tag=ab8asdasd9Call-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Length: 0
Upon receiving the “200 OK” from the second CPM client in step 105, the CPM server 2 forwards a “200 OK” message having a configuration as shown in Table 4 to the CPM client 1 in step 107.
TABLE 4SIP/2.0 200 OKVia: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4From: sip:user1@domain.com;;tag=49394To: sip:user2@domain.com;tag=ab8asdasd9Call-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Length: 0
The SMS follows the protocol defined in 3GPP [TS 23.040]. FIG. 2 illustrates a typical message processing flow when a first Mobile Station (MS) 4 sends a Short Message (SM) to a second MS 6 via a Short Message Service Center (SMSC) 5.
In step 201, the first MS 4 submits an SM to the SMSC 5 by using an SMS_SUBMIT Protocol Data Unit (PDU). At this time, the first MS 4 can also request an SMS status report (SMS_STATUS_REPORT).
Upon receiving the SMS_SUBMIT PDU, the SMSC 5 confirms the reception of the SMS_SUBMIT PDU by sending an SMS_SUBMIT_REPORT PDU back to the first MS 4 in step 203.
In step 205, the SMSC 5 forwards the SM to the second MS 6 through an SMS_DELIVER PDU. Then, in step 207, the second MS 6 acknowledges the reception of the SM by sending an SMS_DELIVER_REPORT PDU back to the SMSC 5. Upon receiving the SMS_DELIVER_REPORT PDU, the SMSC 5 sends an SMS_STATUS_REPORT PDU to the first MS 4 to report that the SM was successfully delivered to the second MS 6 in step 209.
The SMS_SUBMIT PDU includes information elements (from [TS 23.040]) as shown in Table 5.
TABLE 5Abbr.ReferenceP1)P2)DescriptionTP-MTITP-Message-Type-IndicatorM2bParameter describing the messagetype.TP-RDTP-Reject-DuplicatesMbParameter indicating whether or notthe SC shall accept anSMS-SUBMIT for an SM still heldin the SC which has the sameTP-MR and the same TP-DA as apreviously submitted SM from thesame OATP-VPFTP-Validity-Period-FormatM2bParameter indicating whether or notthe TP-VP field is present.TP-RPTP-Reply-PathMbParameter indicating the request forReply Path.TP-UDHITP-User-Data-Header-IndicatorObParameter indicating that the TP-UDfield contains a Header.TP-SRRTP-Status-Report-RequestObParameter indicating if the MS isrequesting a status report.TP-MRTP-Message-ReferenceMIParameter identifying theSMS-SUBMIT.TP-DATP-Destination-AddressM2-12oAddress of the destination SME.TP-PIDTP-Protocol-IdentifierMoParameter identifying the above layerprotocol, if any.TP-DCSTP-Data-Coding-SchemeMoParameter identifying the codingscheme within the TP-User-Data.TP-VPTP-Validity-PeriodOo/7oParameter identifying the time fromwhere the message is no longer valid.TP-UDLTP-User-Data-LengthMIParameter indicating the length ofthe TP-User-Data field to follow.TP-UDTP-User-DataO3)
The SMS_DELIVER PDU includes information elements (from [TS 23.040]) as shown in Table 6.
TABLE 6Abbr.ReferenceP1)R2)DescriptionTP-MTITP-Message-Type-IndicatorM2bParameter describing the messagetype.TP-MMSTP-More-Messages-to-MbParameter indicating whether or notSendthere are more messages to sendTP-RPTP-Reply-PathMbParameter indicating that Reply Pathexists.TP-UDHITP-User-Data-Header-IndicatorObParameter indicating that the TP-UDfield contains a HeaderTP-SRITP-Status-Report-IndicationObParameter indicating if the SME hasrequested a status report.TP-OATP-Originating-AddressM2-12oAddress of the originating SME.TP-PIDTP-Protocol-IdentifierMoParameter identifying the abovelayer protocol, if any.TP-DCSTP-Data-Coding-SchemeMoParameter identifying the codingscheme within the TP-User-Data.TP-SCTSTP-Service-Centre-Time-M7oParameter identifying time when theStampSC received the message.TP-UDLTP-User-Data-LengthMIParameter indicating the length ofthe TP-User-Data field to follow.TP-UDTP-User-DataO3)
The TP-UD (User Data) contains the message to be sent. The message can be preceded by a header inside the TP-UD. The presence of the header is indicated by the TP-UDHI (User Data Header Indicator) information element, i.e., a TP-UDHI set to “1” indicates that TP-UD is a header.
The header in the TP-UD may be structured as shown in Table 7 (from [TS 23.040]).
TABLE 7FieldLengthLength of User Data Header1 octetInformation-Element-Identifier “A”1 octetLength of Information-Element “A”1 octetInformation-Element “A” Data0 to “n” octetsInformation-Element-Identifier “B”1 octetLength of Information-Element “B”1 octetInformation-Element “B” Data0 to “n” octetsInformation-Element-Identifier “X”1 octetLength of Information-Element “X”1 octetInformation-Element “X” Data0 to “n” octets
The “Information-Element-Identifiers” are predefined values; they all refer to a specific meaning. The list of identifiers and their meaning (for SMS only) are shown in Table 8 (from [TS 23.040]):
TABLE 8VALUEClassifica-(hex)MEANINGtionRepeatability00Concatenated short messages, 8-bitSMS ControlNoreference number01Special SMS Message IndicationSMS ControlYes02ReservedN/AN/A03Value not used to avoidN/AN/Amisinterpretation as <LF>character04Application port addressingSMS ControlNoscheme, 8 bit address05Application port addressingSMS ControlNoscheme, 16 bit address06SMSC Control ParametersSMS ControlNo07UDH Source IndicatorSMS ControlYes08Concatenated short message, 16-SMS ControlNobit reference number09Wireless Control Message ProtocolSMS ControlNote 3. . .. . .. . .. . .1B-1FReserved for future EMS featuresN/AN/A(see subclause 3.10)20RFC 822 E-Mail HeaderSMS ControlNo21Hyperlink format elementSMS ControlYes22Reply Address ElementSMS ControlNo23Enhanced Voice Mail InformationSMS ControlNo24-6FReserved for future useN/AN/A70-7F(U)SIM Toolkit Security HeadersSMS ControlNote 180-9FSME to SME specific useSMS ControlNote 2A0-BFReserved for future useN/AN/AC0-DFSC specific useSMS ControlNote 2E0-FFReserved for future useN/AN/ANote 1: The functionality of these IEIs is defined in 3GPP TSG 31.115 [28], and therefore, the repeatability is not within the scope of this document and will not be determined here.Note 2: The functionality of these IEIs is used in a proprietary fashion by different SMSC vendors, and therefore, are not within the scope of this technical specification.Note 3: The functionality of these IEIs is defined by the WAP Forum and therefore the repeatability is not within the scope of this document and will not be determined here.
The message transmission according to the above-mentioned process may be performed either only once between two users or repeatedly multiple times between the same two users. That is, the users may exchange messages like a conversation through the SMS or CPM service. In this process, two users can handle a conversation by just exchanging a series of messages to each other without explicitly establishing a session beforehand. Therefore, messages that are transmitted to or received from the same counterpart are displayed on an individual window of a user. The same concept is also applicable to the CPM service in which messages are transmitted/received after setup of a session. It is impossible to display a set of messages, which a CPM client has transmitted to or received from the same counterpart according to the CPM service, in a single window, for example, a conversational view. Further, it is also impossible to provide a conversational view including previously exchanged messages in the case of restarting the conversation later, because messages are not bound to any particular session, and thus are not linked to each other.